-
Notifications
You must be signed in to change notification settings - Fork 930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support node.js 16 and bump node.js 12 version. #1439
Conversation
2adc3fa
to
6593716
Compare
Is there an ETA for this release? The older version of Node 12 fails Trivy scans with 14 HIGH CVE failures. |
@ethomson FYI. ☝️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM left a thought
it says 2.285.0 was released 2 days ago but our runners are still showing 2.284.0 https://github.com/actions/runner/releases/tag/v2.285.0 I tried to update an action to use node16 but its failing because the runners aren't using 2.285.0 - how do we force them to use the latest release (these are not custom runners, they are the default runners) |
Why skip 14 entirely?? Shouldn’t actions support every LTS version of node? |
Sorry for the inconvenience @bryantbiggs - 2.285.0 was released, but it takes time to get that updated across our runner fleet and against our services. We'll announce on https://github.blog/changelog/ once this is generally available. We expect this to complete on Thursday but it could be delayed (as any deployment can be).
If you're running self-hosted runners, you can feel free to download the newest version yourself and run it. But if you're using GitHub-hosted runners, you'll need to wait for our deployments. |
We're intentionally conservative about the Node versions that we bundle in the runner application - and that you can subsequently author actions in - because this is something that we need to support even after Node.js leaves LTS. (We still support actions written as containers from the original Actions v1 before they were GA'd, before we moved to a JavaScript runtime model.) By skipping LTS lines, we're able to keep the support matrix smaller. Our hosted runner virtual machines, of course, have all the various versions of Node.js installed (or can download them on-demand). Are you trying to author an action and need Node.js 14 support explicitly, and neither Node.js 12 nor Node.js 16 will work? |
I don't have a concrete scenario at the moment, because I can't try upgrading my actions to node 16 until #1439 (comment) :-) However, I could easily see a scenario where I'm using a compiled dependency - like node-sass (a problem i'm running into right now with storybook on react-dates, which only installs on node <= 14) - that only works on node 14, and thus I'd be screwed with the current scenario (where i can't use node 14 syntax on node 12, but i can't use node-sass on node 16). Generally, dependencies will always work, eventually, on any node version that will become or has been LTS, but that can be a slowly moving window. Is there a reason that it couldn't work more like setup-node, where the action can use whatever version of node the setup-node action uses? |
Indeed. We move slowly here, too as a result. 😁
Let me put a pin in the "more like setup-node" part of that question and come back to it. If we remove the "more like" then the question becomes "Is there a reason that it couldn't use whatever version of node the setup-node action uses", then action authors can't reliably know what runtime they're targeting. If a user ran (I don't mean to make this a strawman, this is a totally reasonable approach if you're building workflows and writing your own actions for those workflows. But the actions in the marketplace are meant to be used more broadly and so actions authors need be able to write an action and give a platform requirement for running it. That way an action can specify that it needs node16 and use top-level await (for example) even if a user So the runner brings a copy of Node.js to the party so that we can ensure consistency and availability - that an actions author can always ask for Node 16 and that we can always make it available. This is largely because we need to support an individual action across so many different environments. The GitHub Actions managed runner VMs are easy because we own them. (We can - and do - just put Node.js versions on the runners.) Self-hosted runners are the tricky part - we want to be able to run a workflow, including one with actions, one whatever the user already has, just by installing our runner. This expectation is even moreso with containers, which users typically build as small as possible and may even be taking off the shelf. Anyway, that's the reason that we don't do every LTS today (to avoid bloating the runner). I do think that there are opportunities to make this more flexible in the future. @TingluoHuang is fixing our upgrade story so that the runner will download deltas to self-update, instead of downloading the whole package. This will help us as we're adding new Node.js versions. Coming back to the "more like" piece that I tried to artfully dodge earlier. I'd be a lot more cautious about adding a "runs-on: node14" and making users supply that Node.js 14 runtime (meaning that your action will work on GitHub hosted runners and users would need to configure their own runners to support it). We'd need to make improvements to the runner to detect these problems and fail gracefully, but it's an idea with merit. |
Oh I didn't mean to suggest that the consumer had to bring a node - altho that seems useful too as an option - but more that maybe the action itself could use its own node via setup-node, so that this action doesn't require any changes in the future to install any arbitrary node version. |
looking forward to version 2.285.0 be released. |
It looks that version 2.285.0 is now rolling out 🎉 |
Hey folks. Is it possible that merging this made
We could check that the job would indeed run everything with
Also @ethomson to your comment about Node 12 or Node 16 being enough: It is worth mentioning Node 14 does add some interesting features unsupported in Node 12 and given Node 16 completely changes lock file implementation supporting Node 14 from a consumer perspective really makes sense. |
We're not seeing any widespread reports of this, and we're seeing successful workflow runs that are using node12 based actions (which is most workflows, since |
The specific issue was that the way we passed an We had previous runs of this job (the last was from last night) in which the issue didn't happen. We use |
@p4bloch Interesting. I'd love to see your workflow file and actions metadata. Are these in a public repo that you can share? |
hey all 👋 i'm seeing odd behavior with my previously stable Node.js CI pipeline. TL;DR - i need to use more details here: |
Note that the node in your workflow (setup-node, env, etc) or the node in your environment are orthogonal and not related to the node the runner carries as a runtime to exec actions. |
@bryanmacfarlane ok. i guess i don't understand how to ensure the correct version of |
Yeah, setup-node or actions/virtual-environments (the os image which changes and changes node version in your path) issue is probably the best place for the issue. running |
node 16 is now supported in gh actions. Ref: actions/runner#1439
also update tsconfig.json to follow the recommendation in the wiki: https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping#node-16 refs actions/runner#1439
also update tsconfig.json to follow the recommendation in the wiki: https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping#node-16 refs actions/runner#1439
https://github.com/github/c2c-actions-runtime/issues/1522
#1294